home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0086 / 487.txt < prev    next >
Text File  |  1997-04-16  |  11KB  |  267 lines
  1. =========================================================================
  2.  
  3. INFO-ATARI16 Digest         Sat, 28 Apr 90       Volume 90 : Issue  487
  4.  
  5. Today's Topics:
  6.                       An Apology to Word Perfect
  7.                           HAPPY COMPUTER BBS
  8.                       Help, where can I get LINT
  9.                Looking for graphics/animation software
  10.                          Mac Emulators on ST
  11.                       Ramdisk bootup (Code RAM)
  12.                       STE TOS / TOS 1.4/1.6 etc.
  13. ----------------------------------------------------------------------
  14.  
  15. Date: 27 Apr 90 23:12:43 GMT
  16. From: haven!aplcen!jhunix!jheddy@purdue.edu  (Jared Brennan)
  17. Subject: An Apology to Word Perfect
  18. Message-ID: <5088@jhunix.HCF.JHU.EDU>
  19.  
  20. In article <5873.263811fd@uwovax.uwo.ca> 35002_3025@uwovax.uwo.ca writes:
  21. >       There should be a student price on Word Perfect at about $200...
  22. >Kevin-john Conway
  23. >35002_3025@uwovax.uwo.ca
  24.  
  25.      This has been discussed a couple of times.  The gist of what I've
  26. read is that, for every version of WordPerfect, be it Atari, PC, Mac,
  27. or whatever, there is a student discount price of $99.  Every dealer
  28. who sells WordPerfect should honor this price.  They should have the
  29. forms WordPerfect Corp. supplies for student discounts.  If they don't,
  30. well, call up WordPerfect and complain and then go someplace else.
  31.  
  32. --
  33. . . . Yet another shallow and badly thought-out opinion from:
  34. Jared Brennan <jheddy@jhunix.hcf.jhu.edu>       BITNET: JHEDDY@JHUNIX,JHUVMS
  35. ARPA: jheddy%jhunix@hopkins.ARPA        UUCP: allegra!hopkins!jhunix!jheddy
  36.  
  37. ------------------------------
  38.  
  39. Date: Sat, 28 Apr 90 13:49:33 SST
  40. From: "S. Sujarittanonta" <AKISUJAR%NUSVM.BITNET@CUNYVM.CUNY.EDU>
  41. Subject: HAPPY COMPUTER BBS
  42.  
  43. Hello from Singapore,
  44.  
  45. I learn that the Happy Computer Inc, Maker of the Discovery Cartridge has put
  46. up the latest version of their software for the user to download on the Happy
  47. BBS. I own one of the cartridge with software version 2.7 and would like to
  48. updated mine to the latest version.  However it is impossible for me to logon
  49. the US BBS from Singapore. I wrote to the Happy Computer several time but never
  50. get any reply from them.
  51.  
  52. I shall be most grateful if anyone will be kind enough to e-mail me the update
  53. file and the BETA version software which can convert the Atari 8 Bit diskette
  54. to ST format. I heard that both are in small ARC format files.
  55.  
  56. Thank in advance,  Suthipuntha.  School of Architecture,
  57.                                  National University of Singapore
  58.                                  AKISUJAR@NUSVM.BITNET
  59.  
  60. ------------------------------
  61.  
  62. Date: 28 Apr 90 02:13:10 GMT
  63. From: cs.umn.edu!thelake!steve@ub.d.umn.edu  (Steve Yelvington)
  64. Subject: Help, where can I get LINT
  65. Message-ID: <A2846168219@thelake.mn.org>
  66.  
  67. In <9004270944.AA03533@ucbvax.Berkeley.EDU>,
  68.    S61304@PRIME-A.POLY-SOUTH-WEST.AC.UK ("Simon Chappell") writes...
  69.  
  70. > Does anyone know where I can get a copy of LINT that I can use with
  71. > Sozobon 1.01 (I'd use it with 1.2 if I could get working binaries!)
  72.  
  73. I know of no version of lint for the ST.
  74.  
  75. Working 1.2 binaries were posted to comp.binaries.atari.st.
  76. They should be available from panarthea and terminator.
  77.  
  78. > I need it in sort of a hurry as I keep shooting myself in the feet and it
  79. > would be very useful to use it before starting another long error doomed
  80. > compile!
  81.  
  82. Keep your modules short, or your code perfect, whichever is easier.
  83.  
  84. > Also, does anyone have any short comments on how to use MAKE? I have split
  85. > my main program up so that it covers a number of smaller .c files, but at
  86. > the moment I am doing the following:
  87. >
  88. > #include "filename.c"
  89. >
  90. > I realise that this is possibly not the best thing to do as I am constantly
  91. > recompiling code that is tested and debugged, so I need help!
  92.  
  93. Eek! Simon, that's not the way to do it. No wonder your compiles are long.
  94.  
  95. cc.ttp has a -c switch that means "just compile the file, and don't link
  96. it." If you do this:
  97.  
  98. cc -O -c file1.c
  99.  
  100. you'll wind up with file1.o in the directory, assuming it passed the tests.
  101. Repeat the process with the other modules. When you're done, link them:
  102.  
  103. cc -o program.tos file1.o file2.o file3.o
  104.  
  105. et cetera. You can mix .c, .o and .s filenames on the command line,
  106. plus libraries (.a files, or files with no extension).
  107.  
  108. "make" is another animal entirely. It knows how to use cc.ttp efficiently,
  109. but it's not a very friendly program. And Sozobon's make.doc is of little
  110. help.
  111.  
  112. Nevertheless, here is a sample makefile. I'm not a make wizard, but it
  113. appears to work. Yes, I did test this one. :-)
  114.  
  115. # Generic makefile for constructing GEM applications
  116. # with Sozobon C and GEMFAST.
  117. # Change CFLAGS, OBJECTS and PROGRAM as needed
  118. # and leave everything else alone.
  119.  
  120. OBJECTS=file1.o file2.o file3.o
  121. PROGRAM=program.prg
  122. CFLAGS=-v -O
  123. GEMLIBS=aesfast.a vdifast.a
  124.  
  125. $(PROGRAM):     $(OBJECTS)
  126.                 $(CC) $(CFLAGS) -o $(PROGRAM) $(OBJECTS) $(GEMLIBS)
  127. #               (Notice how this translates when make is run.)
  128. # end
  129.  
  130.  
  131. The format appears to be
  132.  
  133. target:<tab>dependencies
  134. <tab><tab>command line
  135.  
  136. Make looks for "makefile" by default; you can run "make -f altfile" and it
  137. will look for an alternate makefile "altfile" instead.
  138.  
  139. --
  140.    Steve Yelvington at the lake in Minnesota
  141.    steve@thelake.mn.org
  142.  
  143. ------------------------------
  144.  
  145. Date: 28 Apr 90 04:46:18 GMT
  146. From: usc!chaph.usc.edu!nunki.usc.edu!rjung@ucsd.edu  (Robert allen Jung)
  147. Subject: Looking for graphics/animation software
  148. Message-ID: <9465@chaph.usc.edu>
  149.  
  150. In article <9004270406.AA24279@fsucs.cs.fsu.edu> boyd@nu.cs.fsu.edu (Mickey
  151.  Boyd) writes:
  152. >In article <11682@portia.Stanford.EDU>, macross@portia.Stanford.EDU (Chris
  153.  Adamson) writes:
  154. >>      Has anyone out there seen any software product that could be used
  155. >>in producing animation on the ST (with somewhat more flexibility than, say,
  156. >>"Degas Elite" with the minimal color-switching stuff)?  I'm looking for
  157. >>something along the lines of "Aegis Animator" (which I saw for lesser 68000
  158. >>machines).
  159. >
  160. >I have seen something called Art and Film Director that is pretty neat
  161.  
  162. The two primary (as far as I know) animation programs are CYBERPAINT by Antic
  163. software and ART & FILM DIRECTOR (it's a boxed set) by Epyx.
  164.  
  165. CYBERPAINT strong points: It animates by "delta animation". The computer
  166. animates by storing the changes between each frame. This is nice because small
  167. animation changes take up less RAM, meaning you can get more frames of
  168. animating in. It's also easy to use -- you draw each frame and the computer
  169. does all the processing. CYBERPAINT also has lots of built-in special effects
  170. that you can do in a sequence of frames (rotate a graphics block n degrees
  171. in 10 frames, etc.)
  172.  
  173. CYBERPAINT weak points: With delta animation, large changes (scene 1 to scene
  174. 2) take up LOTS of memory. Generally, quality Cyber animations take from
  175. 2 to 4 megabytes. CYBERPAINT does not support sound, and drawing each
  176. individual frame can be tedious.
  177.  
  178.  
  179. ART & FILM DIRECTOR strong points: It animates by a computer equivalent of
  180. cel animation (Disney et al). Art is drawn on one of 16 screens. Rectangular
  181. blocks of the screens is then "clipped" for cels, which can be arranged in
  182. groups for easier manipulation. Less memory is used by A&F, and prepackaged
  183. sounds/musics can be used (30 sounds are provided, and you can select up to
  184. 10 for your animation. There is/was also an expansion disk with sample frames
  185. and sounds). Generally, you would use ART DIRECTOR to draw the screens, then
  186. FILM DIRECTOR to create your animation. Full scene changes do not take any
  187. extra memory, aside from that used to store the image itself.
  188.  
  189. ART & FILM DIRECTOR weak points: Animation can become repetitive easily,
  190. since your animation is limited to how many cels you create. Customized
  191. sounds and music is nonexistent. The animation process is more confusing than
  192. CYBERPAINT, though the manual has a quality tutorial to guide you through
  193. the tools. Epyx has gotten out of the computer software business, so this
  194. program is harder to find (The Atari ST magazines have mail-order ads, they
  195. can probably get you the A&F package for $20 [originally priced at $70, it's
  196. a steal!])
  197.  
  198.  
  199.   I would suggest you look at what you're trying to do, then pick the tool
  200. appropriate for the task. Personally, I find ART & FILM DIRECTOR to be more
  201. flexible to use than CYBERPAINT, but I like to generate animation similar to
  202. "traditional" animation.
  203.  
  204.                                                 --R.J.
  205.                                                 B-)
  206.  
  207. """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
  208. Opinions expressed here are mine and mine alone. If you want them, go for it!
  209.  
  210.                                         Send replies to rjung@nunki.usc.edu
  211. """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
  212.  
  213. ------------------------------
  214.  
  215. Date: 28 Apr 90 04:50:53 GMT
  216. From: fernwood!portal!cup.portal.com!Dave_Ninjajr_Flory@apple.com
  217. Subject: Mac Emulators on ST
  218. Message-ID: <29384@cup.portal.com>
  219.  
  220. Yes, the ST does have non-interlace hi-res. The Spectre GCR reads and runs
  221. every Mac program I have tried directly from a Mac disk. There are some
  222. mostly copy protected ones that won't run, but all the big productivity
  223. stuff works just fine. The screen is about 15-20% bigger and it runs a little
  224. faster than a Mac Plus. A very viable alternative to the Mac.
  225.  
  226. ------------------------------
  227.  
  228. Date: 28 Apr 90 04:50:53 GMT
  229. From: fernwood!portal!cup.portal.com!Dave_Ninjajr_Flory@apple.com
  230. Subject: Ramdisk bootup (Code RAM)
  231. Message-ID: <29383@cup.portal.com>
  232.  
  233. >>There was a PD program called TPORT that loads a ramdisk at bootup.
  234. >>I use it in conjunction with CODERAM (from Codehead Utilities)
  235. >>or Pagestream. I have all the fonts autoload into a ramdisk, then
  236. >>switch disks and run
  237.  
  238. If you have CodeRam then why are you using the other program. If you
  239. have the documentation you should have gotten when you bought
  240. Codehead Utilities you would know that with CodeCopy you can make a
  241. .CCP file which is an image of the stuff in the CodeRam disk. The ram
  242. disk can be configured to automatically load this file and run it on
  243. boot up. On a warm reset the computer boots from the Ramdisk, VERY
  244. fast.
  245.  
  246.  
  247. ------------------------------
  248.  
  249. Date: 28 Apr 90 03:55:50 GMT
  250. From: pwp@iuvax.cs.indiana.edu  (Paul Purdom)
  251. Subject: STE TOS / TOS 1.4/1.6 etc.
  252. Message-ID: <43420@iuvax.cs.indiana.edu>
  253.  
  254. I believe that one can learn a lot by disassembling ROM code. I remember
  255. learning a lot form reading the TRS80 code. Of course, it does take a long
  256. time, and if you just want to write programs that work well then take Allan's
  257. advise. This is particularly important if you are going to write a program
  258. that is going to become popular. Sometimes I think Allan is a little
  259. overly concerned about the kinds of trouble we can get into by our selves,
  260. but then he often has to spend much more time dealing with some of these
  261. mistakes than we do. Cheap acturate information would be a great help.
  262.  
  263. ------------------------------
  264.  
  265. End of INFO-ATARI16 Digest V90 Issue #487
  266. *****************************************
  267.